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Abstract 

Secure routing protocols for mobile ad hoc networks 
have been developed recently, yet, it has been unclear what 
are the properties they achieve, as a formal analysis of these 
protocols is mostly lacking. In this paper, we are concerned 
with this problem, how to specify and how to prove the cor- 
rectness of a secure routing protocol. We provide a defini- 
tion of what a protocol is expected to achieve independently 
of its functionality, as well as communication and adversary 
models. This way, we enable formal reasoning on the cor- 
rectness of secure routing protocols. We demonstrate this 
by analyzing two protocols from the literature. 



1. Introduction 

A number of protocols have been recently developed 
to secure the route discovery in mobile ad hoc networks, 
e-g> ATI l20l [181 [Toll . Informally, secure routing proto- 
cols provide mechanisms that prevent adversaries, that is, 
nodes that deviate from the protocol definition, from influ- 
encing, controlling, or abusing the route discovery. For ex- 
ample, adversaries should be prevented from impersonating 
network destinations, advertising unreachable destinations, 
links that do not reflect the actual network connectivity, or 
misleading their peers that a destination can be reached at a 
lower (higher) cost than the actual one. 

At first, such requirements depend on the functionality 
of the routing protocol. In spite of a variety of secure rout- 
ing protocols for ad hoc networks proposed in the literature, 
there is no definition of what a protocol should achieve in- 
dependently of how it operates. In other words, differing 
solutions have been developed without a specification. 

Moreover, the requirements themselves do not capture 
the characteristics of the communication environment and 
the adversary. The literature so far assumes mostly a de 



facto data link layer protocol on top of which the routing 
protocol operates. At the same time, the capabilities of the 
adversaries have not been explicitly defined, either in terms 
of what the adversaries know or what can be their actions. 

Finally, the security of different protocols has been an- 
alyzed mostly through informal arguments, with a small 
number of works taking a formal approach ifTTl [191 but 
not addressing all the above-mentioned problems. 

Our contribution here is a specification, that is, a defi- 
nition of the sought properties for any candidate protocol, 
independently of the protocol's design and mechanisms. In 
particular, we define the properties of the protocol's output, 
one or more discovered routes. We say that a protocol is cor- 
rect if it satisfies the specification. Furthermore, we define 
an adversary model, also independent of the protocol func- 
tionality. In addition, we outline a network communication 
model that captures the features of the ad hoc paradigm. 
With these components, we form a framework to enable 
formal reasoning on the properties of any secure routing 
protocol. To illustrate this, we analyze two secure routing 
protocols. Finally, we discuss related and future work. 

2. System Model 

2.1. Network Model 

Mobile hosts move freely within some geographical area 
and collaboratively support the network operation, without 
necessarily pursuing a common objective or running the 
same application. The network connectivity and member- 
ship can change frequently, and so does the network area 
reachable by the migrating mobile hosts. Connectivity may 
be intermittent even when hosts are fairly stationary, e.g., 
when their peers alternate between 'sleep' and 'active' peri- 
ods. 

We define a network node as a process with (i) a unique 
identity V, (ii) a public/private key pair Ey, Dy, (iii) a 



module implementing the networking protocols, e.g., rout- 
ing, and (iv) a module providing communication across a 
wireless network interface. As mobile hosts may have more 
than one network interface [9], more than one node may 
run on a mobile host. It is convenient to view mobile ad 
hoc networks as systems with a single node per mobile de- 
vice; however, such a consideration is not necessary for the 
results presented here. 

We focus on the network operation above the data-link 
layer. The node communication at the data-link layer is 
modeled by the following primitives and assumptions, for 
some radius R and time r. 

1. Send^V, m): transmits message m to node V within 
radius R of the transmitting node. 

2. BcastL(m): broadcasts message m to all nodes within 
radius R of the transmitting node. 

3. Receive i(m): receives message m transmitted by a 
node within radius R of the receiver; m is processed at 
a receiver V if m was Beast ^(m) or Send^V, m). 

4. A link (U, V) exists or it is up when two nodes U and 
V are able to communicate directly, i.e., U(V) can re- 
ceive transmissions from V(U). We denote any two 
nodes connected by an up link, and thus capable of 
bidirectional communication, as neighbors. 

5. Links are either up or down, and their state does not 
change faster than the transmission time of a single 
packet. 

6. The network connectivity at a particular instance in 
time is the graph G comprising all up links. 

7. Transmissions from U are received by all nodes V% 
such that (U, Vi) is up during the entire duration of the 
packet transmission. 

8. Packets are delivered across an up link within a max- 
imum link delay r, or they are not delivered at all. In 
the latter case, the delivery failure is reported to the 
upper layer protocol. The data-link layer handles tran- 
sient network failures, it retransmits, but it does not 
duplicate packets. 

Communication across the network is dependent on the 
availability of sufficient resources (bandwidth). The shared 
medium implies that k nodes within R of each other con- 
tend and obtain a portion of the bandwidth, in principle, 
inversely proportional to k. We do not assume that the net- 
work provides fairness, which is beyond the scope of this 
work. In general, the available bandwidth can fluctuate, be 
unevenly distributed among neighbors, adversaries can self- 
ishly attempt to transmit at high rates and the network links 



can be congested. Such failures can either be transient and 
thus masked by the data link layer, or they can persist and 
cause messages to be dropped from the nodes' buffers, or 
prevent nodes from accessing the medium altogether. The 
latter case is equivalent to having all affected links at the 
down state. 

The widely adopted IEEE 802.11 specification, without 
the Wireless Equivalent Protocol (WEP) security mecha- 
nism, provides bidirectional communication according to 
primitives 1-3 and satisfies assumptions 7 and 8 above[] 

In this work, we are concerned with pair-wise commu- 
nication across multiple wireless links between a source S 
and a destination T. We denote S and T as the end nodes, 
and nodes that assist the S, T communication as interme- 
diate nodes. Each node in the network is equipped with a 
certificate; the possession of a certificate does not convey 
authorization or does not imply trustworthiness. Rather, it 
is a minimum requirement for nodes to engage in secure 
communication and provides the means to authenticate the 
origin (or the relay) of network traffic. 

Digital signatures provide a straightforward mechanism 
to authenticate each nodes to all other network nodes. 
Nonetheless, which cryptographic primitives (e.g., symmet- 
ric or public key) are in use, and which nodes' public keys 
a network node knows (or which nodes it shares symmet- 
ric keys with) are orthogonal to our discussion. These are 
issues related with the implementation of any candidate se- 
cure routing protocol. 

2.2. Adversary Model 

We make no assumptions on the motivation of the net- 
work nodes, which either comply with the protocol rules 
(benign behavior), or deviate and actively disrupt the net- 
work operation (malicious behavior). In the former case we 
denote a node as correct, while in the latter as adversary. 
Adversaries have finite processing power and cannot mount 
a cryptanalytic attack to compromise a private or a secret 
symmetric key, or invert one-way or hash functions; as a 
result, cryptographic primitives are assumed secure. Given 
the above assumptions, we consider two models of active 
adversaries: independent and arbitrary adversaries. 

Definition 1: Independent adversaries are network nodes 
that ignore and do not reproduce any received message that 
does not comply with the operation of the networking proto- 
cols, but can generate, modify or replay any other message. 



1 Note that our abstraction of R does not imply an idealized communi- 
cation model; R is a nominal range of direct wireless communication, yet 
this varies and depends both on the Physical Layer protocol and the Signal 
to Interference and Noise Ratio at the receiver. 

2 For a survey of different approaches to equip nodes with certificates 
in the context of ad hoc networks see [14]. 



Non-compliance must be explicitly defined solely with 
respect to the definition of the networking protocol. Any 
message that does not follow the expected, protocol-specific 
format or fails one of the employed protocol checks is 
deemed as non-compliant. We emphasize, however, that 
traffic is non-compliant if and only if the receiving node 
can detect that a message does not comply with the proto- 
col; otherwise, messages that appear to be compliant, but 
actually are not, will be processed as compliant by the pro- 
tocol (and thus by independent adversaries). 

Def. 1 imposes a restriction on the actions of adversaries, 
in that it disallows their reproducing or modifying and re- 
laying any non-compliant message they receive. Nonethe- 
less, Def. 1 allows adversaries to process and thus replay or 
modify compliant messages or generate any message dif- 
ferent than the non-compliant ones they received. Further- 
more, it allows adversaries to act simultaneously, with their 
actions (attacks), in spite of the above discussed constraints, 
possibly having a compound effect. 

Independent adversaries' behavior allows malicious be- 
havior and extends, in a sense, benign failure models that 
consider node crashes, message loss (omission failures 1 8 ] ), 
and message transmission timing failures, when a pre- 
scribed message is sent too early, or too late, or never 0. 
Yet, independent adversarial behavior is protocol-aware 
(but not protocol-specific) and thus it is not out-right more 
general than those failure models^ 

As it will become clear during the protocol analysis, the 
model of independent adversaries, with the imposed con- 
straints, serves as a necessary condition to achieve stronger 
protocol properties than those achieved without the model's 
constraints on the adversarial behavior. In contrast to Def. 
1, we have: 

Definition 2: Arbitrary adversaries are network nodes that 
can generate any message, and replay or modify any re- 
ceived message. 

Adversaries that mount relatively simple attacks fit in the 
model of independent adversaries. Consider an adversary 
M within the transmission range of an access point or a peer 
that allows high bit-rate data download or video stream ac- 
cess. M can disrupt the route discovery to ensure that no 
or few routes are established across its neighborhood and, 
consequently, little or no network bandwidth is consumed 
by other data flows. Another example is a node that simply 
discards packets to avoid depleting its own resources (bat- 
tery power or CPU cycles), or an adversary that tampers 
with and injects forged routing information in an attempt to 
attract data flows and intercept sensitive information. 

Independent adversarial behavior is such that it precludes 
any action as a consequence of or based on receipt of a non- 

3 For example, an omission-failing node could relay a non-compliant 
message. 



compliant message. Within this definition, one can iden- 
tify preclusion of actions that attempt to assist other ad- 
versaries mounting an attack, if, informally, one considered 
non-compliant traffic attributed to misbehavior. In contrast, 
arbitrary adversaries can perform actions that attempt to as- 
sist ongoing attacks mounted by other adversaries. 

Arbitrary adversaries are more sophisticated and power- 
ful than independent ones, having, for example, knowledge 
of the identities of other adversaries in the network, devot- 
ing resources (e.g., route discoveries) to establish direct and 
possibly private communication with other adversaries, and 
exchanging traffic and information about their local execu- 
tion of the protocol. The model of arbitrary adversaries can 
encompass a range of scenarios, from a handful of attackers 
that collaborate in trying to defeat a network protocol secu- 
rity mechanism, to adversarial nodes deployed, for exam- 
ple, by an industrial adversary to degrade or take advantage 
of the services of another operator, or an enemy that hijacks 
nodes and injects compromised devices in a battlefield. 

3. Routing Specification 

Let N be the set of network nodes and E the set of 
unordered pairs of distinct nodes we denote as edges or 
links. A route is a sequence of nodes Vj G N, and edges 
e M+ i = (Vi,V i+ i) £ E, for < i < n - 1, i.e., 
route = Vo, e ,i, Vi, ei, 2 , Vi, . . . , V n -i, V n . Re- 

ferring to a route as a sequence of nodes implies that for 
any two consecutive nodes of the route (Vi, Vi+i) £ E. We 
call a route with V = S and V n = T an (S, T)-route. 

The routing protocol input is a pair of nodes, S and T. 
Let ti and ti > t\ be two points in time defining a time in- 
terval (t%, ti), with time ti the instance at which the routing 
protocol returns its output to S. When the protocol returns 
its output, we say that the protocol discovers a route. De- 
pending on the output form, we distinguish two classes of 
route discovery: explicit and implicit. 

An explicit route discovery returns a fully and clearly 
expressed, readily observable (S, T)-route, that is a 
Vo, Vx, • • • , Ki-i) Vn sequence of nodes. An implicit route 
discovery is a distributed computation that returns a tuple 
(Vi, Vj+i, Vn), i = 0, . . . , n — 1, of the form {current node, 
relay node, destination), with each (Vi, € E. The 

(S, T)-route is not readily apparent, as the protocol out- 
put to S is a (Vo, V\, Vn)-tuple. Yet, the route is implied 
through a sequence of nodes Vj, 1 < j < n — 1, each of 
them also storing a (Vj, Vj+x, V„)-tuple. 

We term a protocol performing an implicit or explicit 
route discovery defined above as a basic routing protocol. 
A basic routing protocol provides the structure of the route 
but does not provide attributes of the route or its constituent 
nodes and edges. 

Let / : E — » M C -ft be a function that assigns labels, 



that is, real values to edges e^j+i. Each label /(e^i+i) = 
m^i+i € M, which we denote as a Z/n/c metric, provides a 
quantitative description of the e^.i+i attribute(s). For exam- 
ple, a metric can capture the link's reliability or resistance 
to failure, calculated as the fraction of the numbers of deliv- 
ered over transmitted packets across the link. 

The attributes of a route can be 'summarized' by the ag- 
gregate of the labels of e^i+i G (S, T)-route. The aggre- 
gate value is calculated by a function g : M — > 3?, the 
route metric <7(mo,ii . . . , m n _i n ), whose form is protocol- 
dependent. The route metric can be, for example, the sum, 
the product, the minimum, or the maximum of the route's 
constituent link metrics. Moreover, we define to 
be the actual metric value for &a+x, and the aggregate 
<7(/o,i, . . • , l n -\,n) of the actual link metrics as the actual 
route metric. 

We consider an augmented routing protocol. The input 
is S and T, and the output is an (S, T)-route and: (i) for ex- 
plicit discovery, a sequence of labels {7710,1, . . . , m„_i „}, 
with one label for each link of the (S, T)-route, and (ii) 
for implicit discovery, a route metric 5(7710,1, . . . , m n _i, n ) 
over the link metrics distributed to the Vi G (S, T)-route. 

We are interested in routing protocols that ensure the 
three properties in Def. 3 below for the discovered route(s): 
loop-freedom, freshness, and accuracy. Loop-freedom and 
freshness are relevant to both basic and augmented proto- 
cols, while accuracy is relevant only to augmented proto- 
cols. We term a route discovered by a basic (augmented) 
protocol as correct if it satisfies loop-freedom and freshness 
(loop-freedom, freshness, and accuracy). 

Definition 3: 

• Loop-freedom: an (S, T)-route is loop-free if it has no 
repetitions of nodes. 

• Freshness: an (S, T)-route is fresh with respect to an 
interval (t%, £2) if each of the route's constituent links 
is up at some point in time during the interval (t\ ^2). 

• Accuracy: an (S, T)-route is accurate with respect 
to a route metric g and a constant A goo d > if 

l m n-l,n) ~ 9{lo,l, ■ ■ ■ , l-n-l,n)\ < A goo d- 

Loop-freedom is self-explanatory; in our context, the 
property implies that adversaries cannot manipulate or 
abuse the route discovery to create loops. 

Route freshness ensures that each of the constituent links 
of the discovered route was up recently, that is, within a 
(ti, tz) interval prior to the route discovery. We clarify that 
freshness does not guarantee that links were up concurrently 
or throughout (t\ , t^); a link could go down immediately af- 
ter its discovery, or links could be alternately up and down, 
so that a route may never be intact throughout the (t\, tq) 



interval. Freshness prevents the discovery of routes com- 
prising links that existed at no point (were down) during the 
(ti, t-i) interval, and yet are 'advertised' by an adversary. 

Route accuracy provides the additional assurance that 
the quantitative description of a route reflects its actual 
attributes: the route metric calculated by the protocol is 
within A goo< i from the actual route metric. A goo d is a con- 
stant such that, despite malicious or benign faults that lead 
to inaccurate metric values, the route metric is still 'reason- 
ably' close to the actual value and meaningful for the pro- 
tocol. The protocol- and metric-specific A goo d > is al- 
lowed because, even in a benign network, impairments can 
affect measurements and calculations for metric values. Ac- 
curacy prevents adversaries from manipulating the metric 
values, contributing arbitrary metric values, altering metrics 
provided by other intermediate nodes, and misleading end 
nodes into believing that a discovered route is better than it 
actually is. 

The number of route links, or hop count, is a special case 
of a route attribute, with link metric values m^-j+i = 1 
for all i = 0, . . . , n — 1, g() the sum of the m^.j+i, and 
Ag 00 d = 0. The hop count is trivially given by an ex- 
plicit route discovery. But for an implicit discovery it can 
be viewed as a route attribute. 

We emphasize that routes with the properties defined 
above are not guaranteed to be adversary-free. A secure 
routing protocol cannot detect an adversary that fully abides 
with the routing protocol, and only later, once it belongs to a 
utilized route, disrupts the data communication |fl3l . More- 
over, ensuring the correctness of the discovered routes is 
orthogonal to the ability to actually discover one or more 
correct routes. Routes may not be discovered at all times 
due to the compound effect of adversaries' actions and net- 
work impairments. We also note that if either S or T is 
faulty, the protocol does not ensure any of the correctness 
properties. 

4. Secure Routing Correctness 

We analyze the Secure Routing Protocol (SRP), an ex- 
plicit, basic protocol ifTTI . and the augmented version of 
SRP [16|. Using the same framework, we have also an- 
alyzed the Distance- Vector Secure Routing Protocol (DV- 
SRP), an implicit augmented protocol 1151 . and the Secure 
Link State Routing Protocol (SLSP), an explicit basic pro- 
tocol 1 12). These protocols are diverse in terms of their 
design and functionality (reactive vs. proactive, distance- 
vector vs. source routing). However, due to space limita- 
tions, we present here only the analysis of the basic and the 
augmented SRP. The definitions of the two protocols are 
given in the Appendices. 

We assume that traffic relayed by adversaries that act 
as raw data (or signal) repeaters is detected, and that each 



node knows its neighbors (identities and keys). Protocols 
that bound the propagation delay (and thus transmission 
range and distance) for point-to-point data link transmis- 
sions can be used 0. These protocols, as well as protocols 
that use geographical location information, can prevent the 
establishment of 'long-haul' links across the network. Such 
attacks, frequently denoted as 'wormhole attacks,' are not 
specific to the operation of particular routing protocols but 
rather pertain to the neighbor discovery. Secure routing pro- 
tocols either include neighbor-to-neighbor authentication as 
part of the route discovery (e.g., |[T8ll ). or inter-operate a se- 
cure neighbor discovery protocol (e.g., [11]). At the same 
time, wormhole prevention protocols necessitate authenti- 
cation of transmissions between neighboring nodes. We do 
not dwell on the specifics of neighbor- to-neighbor authenti- 
cation, as cryptographic primitives and system assumptions 
vary. 

Lemma 1: Routes discovered by SRP in the presence of 
arbitrary adversaries are loop-free. 

Proof: Let M an arbitrary adversary that attempts to create 
a loop: M can include its own or any other node's iden- 
tity in the NodeList of the RREQ more than once, it can 
replay a RREQ in an attempt to cause other nodes to re- 
forward RREQ and thus re-append their own address, or it 
can receive a RREQ with a loop already formed and relay 
it further. In all cases, the duplicate entries in NodeList 
will be detected by T. Similarly, if M creates or relays a 
RREP with a loop in the Route list, the duplicate entries 
will be detected by S. Note that intermediate correct nodes 
can also detect the loops in the RREQ and RREP pack- 
ets as they relay them; however, it is possible that all S, T 
traffic is relayed only by adversaries. □ 

Lemma 2: Routes discovered by SRP in the presence of in- 
dependent adversaries are fresh with respect to an interval 
{t\,t%), where t\ is the point in time at which S transmit- 
ted a RREQ with identifier Q seeking for T, and ty. is the 
point in time at which S received a RREP in response to 
the query identified by Q. 

Proof: We outline below, for easy reference, the assump- 
tions we rely on, from the system model and the lemma 
statement: (a) each node can identify the source of each 
Beast £0 and Send^Q transmission (nodes know their 
neighbors), (b) traffic is deemed non-compliant if it does 
not follow the format of a RREQ or a RREP and any of 
checks in the protocol definition fails (Apps. A, B), (c) ad- 
versarial nodes act as independent adversaries, (d) each end 
node knows its peer end node (identity and key) (Appen- 
dices A, B). 

Let an RREP carrying a Route — {V n -i ■ ■ ■ , V2, Vi} 
list, and an (S, T)-route being the {S, Vi , V 2 , ■ ■ ■ , K-i , T} 
sequence of nodes. Let (Vi, V^+i) be a link that was never 



up during the interval, with Vi and Vi+i either ad- 

versaries or correct nodes. We will show that no such route 
will be discovered (accepted) by SRP. An adversary can 
cause the inclusion of such a link in a RREQIRREP. 

First, consider an adversary Vk, k > i + 1, tamper- 
ing with the NodeList of a RREQ it receives, remov- 
ing and/or adding one or more node identities and relaying 
the tampered RREQ'. When T responds to and returns a 
RREP, V i+ i executes Send L (V,RREP), as RREP ap- 
pears compliant with the protocol (Steps 4.1-4.3). How- 
ever, Vi does not Receive l(RREP), because (Vi,Vi+\) 
was down at all times during (t\,t%), and thus RREP is 
never received by S. In the special case that Vk is a neigh- 
bor of V, and executes SendL(V,,RREP) upon receiving 
RREP, V. will reject RREP as non-compliant, because 
the node now forwarding the RREP is not Vi's succes- 
sor along RREP's Route (Step 4.1, (a)-(c)), and/or it did 
not previously relay the query that V. had Beast l (RREQ) 
(Steps 2.2.4, 4.2, assumption (a)). Furthermore, if an adver- 
sary M relayed a tampered RREQ" such that M ^ Vi, 
V, G NodeList" , then all Vj nodes and T that execute 
Receive l (RREQ" ) will discard RREQ", because the 
last node in NodeList" is not the neighbor that relays (Step 
2.3.2, assumptions (a)-(c)). 

Second, consider an adversary Vk, k < i, tampering with 
the RREQ NodeList. Then, V i+2 will discard RREQ, ei- 
ther because Vi+i is not its predecessor (Step 2.2.2, (a)-(c)), 
or because it detected a duplicate entry in the NodeList 
(Step 2.2.3), as it must hold that Vk = Vi+i for the adver- 
sary to avoid having the RREQ discarded. 

Third, consider an adversary Vk,k < i, that tampers 
with entries in the RREP Route list, removing and/or 
adding one or more node identities, and then relaying 
the tampered RREP'. All Vj intermediate nodes with 
1 < j < k relay RREP', since it appears compliant 
with the protocol. However, S will discard RREP', be- 
cause f K (S,T,Q, Route') ^ f K (S,T,Q, Route) (Step 
4.5). Furthermore, if an adversary M relayed a tampered 
RREP" such that M ^ V and G Route", then 
all Vj nodes (and S) that execute ReceiveL() will discard 
RREP", because their successor along the RREP" Route 
is not the neighbor that relays RREP" (Step 4.1, (a)-(c)). 
In the special case that the adversary impersonates T, V, 
discards the RREP because its successor is not T (Step 
4.1, assumptions (a)-(c)). 

Fourth, consider an adversary Vk, k < i, which, upon 
receipt of a RREQ, generates a RREP'" with a Route'" 
that includes (V,V +1 ), and Send L (V k -i, RREP'"). All 
Vj, 1 < j < k, intermediate nodes relay RREP'", which 
appears to be compliant with the protocol. However, S dis- 
cards RREP'", because f K (S,T,Q, Route) ^ A'", with 
A'" the authenticator the adversary appended to RREP'" 
(Step 4.5, assumption (d)). 



Finally, consider an adversary Vk,k < i, transmitting a 
RREP generated by T and identified by Q' Q. Assum- 
ing that all (Vj, Vj+i) links of the RREP Route are up for 
1 < j < k, all intermediate nodes Vj deem the RREP 
compliant and relay it towards 5. However, S maintains the 
value of Q that identifies RREQ of the current route dis- 
covery (App. A). Thus, it discards any RREP generated 
by T and identified by Q' ^ Q as non-compliant, because 
f K (S,T,Q, Route) ^ A' = f K (S,T,Q' , Route) (Step 
4.5). Moreover, the adversary cannot forge a RREQ from 
S seeking for T and identified by Q before time t\, and thus 
mislead T to respond with a RREP identified by Q. As a 
result, the adversary cannot send such a RREP to S after 
S actually transmits a RREQ identified by Q, because T 
responds with a route reply only to RREQ whose origin is 
S (Steps 1.1.4, 2.3.4, assumption (d)). □ 

For the augmented version of the protocol, all nodes 
use the same algorithm to calculate or estimate m^i+i for 
their incident links. For (Vi,Vi + \), we denote the met- 
ric calculated by Vi as m\ i+l and the one calculated by 



J+i 



Vi+i as m\j +1 . SRP requires that m\ i+1 — 
\m\ i+1 — Tn^\ +1 1 < e for some e > 0, a protocol-selectable 
and metric-specific threshold that determines the maximum 
allowable discrepancy between m l ii+1 and Despite 
the assumed symmetry of the link, e allows for inaccuracy 
due to network impairments that may affect measurements 
necessary for the metric calculation. If the metric in use is 
a fixed, 'administrative' cost agreed upon between the two 
neighbors, then m* i+1 = m^ +1 must hold. Metrics such 
as the willingness of the node to relay data, or its remain- 
ing battery power, can be determined only independently at 
each node and do not fit in the above definition. 

If ff(mj ;1 , . . . , m£_ 1; J = ™%i+i> we denote ^ 

function g as g add and the constant A good as A a g ^ d , if 
#(mJ ;1 ,...,m™_ 1; J = max <,< n _ i {m ?+^} the func- 
tion is denoted as g max and the constant as A™°5> an d 
if g( m k.n • ■ • j m n-i,n) = min <i<„_i {m^J as g mm 
andAjp. Form^ > 0, g{m^ >u . . . , m^_ 1; J = 
U7=o to m+i can be written as g a dd{ml tX , . . . ,m™_ 1 „), 
where m^ +1 = log(m-+ +1 ), for < « < n — 1. 

Lemma 3: Routes discovered by SRP in the presence of in- 
dependent adversaries are accurate, with respect to ( i) g a dd 
and Af Q d od = n 2 e + n~5, (ii) g max and A™ a d = ne + 5, 
and ( Hi) g m in and A™"^ = ne + 8, with n the number of 
route links, e > the maximum allowable difference be- 
tween m\ i+1 and m^ +1 , and 8 > the maximum error 
for a metric calculation by a correct node. 

Proof: Consider an adversary Vi that modifies one or more 
of the MetricList entries, relaying a RREP with a tam- 



pered MetricList' . S will discard such a RREP, because 
f K (S,T,Q, Route, MetricList') ^ A'. Next, consider 
an adversary Vi that tampers with one of the values in the 
MetricList, for j < i — 1, and relays a RREQ with 
the tampered metric list. The RREQ appears as protocol- 
compliant to intermediate nodes and T, which generates a 
RREP. When RREP arrives back at Vj,m s ,i-m' Si ^ 0, 
and Vj rejects RREP as non-compliant. 

Moreover, let Vi tamper with one of the in the 
MetricList, for j > i, and relay RREQ with a tam- 
pered metric list. Then, V^+i will reject RREQ as non- 
compliant, because all m J jj +1 <E MetricList for j > i 
must be void, as these entries correspond to links not yet 
discovered. If Vi appended one or more additional entries 
to NodeList, RREQ would be discarded as Vi's neighbors 
Receive l{RREQ) with the last node in NodeList differ- 
ent from its precursor (Step 2.2.2). 

Next, consider an adversary Vi that appends an erro- 
neous link metric, with 8i > denoting the metric calcu- 
lation error with respect to the actual link metric; m\_ xi = 
i»— i,i ± Si and m\ i+1 = ± Si. V-i deems a 

RREQ/ RREP as compliant only if Vi appends m\_ x i 
such that \ml_ 1 i — rn % ~_\ J < e. For the discovery of an 
(S, T) -route with k nodes, the above inequality must be true 
for all 1 < i < n. We consider the worst case, with S and T 
correct, i.e., So < 8 and S n < 8, and all intermediate nodes 
adversaries. 

Then, for the first link |m[J 1 — mj x | = |Z ,i±<5o — Go,i± 
8i)\ < e =>• Si < e + 8; for the second link, \m\ 2 ~rn\ 2 \ = 
\h, 2 ±8x- (h t2 ± S 2 )\ < e 8 2 < e + Sx < 2e + 8 and, 
in general, Si < ie + 8. 

Similarly, for the route links in the reverse order, 



,71-1 



< e => S„ 



"n-i,n ~~ ""n-i,ni ^ c ~^ < e + 8, and in gen- 

eral Si < (n — i)e + S. Thus, Si < min{ie + 6, (n — i)e + 8} 
for 1 < i < n — 1. Since 8 does not depend on n, i, and e, 
Si < min{ie, (n — i)e} + 8. 



Then, for g add = Ya=u 



i+i 



i Zn-l,n) ± 



, and we select = 



J2i=i Si ± 8. The sum is bounded since each Si term is 
bounded: Yh=i s i < S™=i 1 ( mm {* e ; ( n - *) e l + S) = 

(e^f^ + {n-l)5 if n is odd, 

1 e 1 ^ + (n — 1)5 if n is even 
n 2 e + n8. 

Then, for j mal we get similarly: 

gmax = niaXo<i<„-l{Zi ; i + i ± S i+ i} 

{maxo<i< n -i{ii,i+i} + niax <i<„-i{(5i} 
max <i<„-i{^i + i} - min <i<„_i{5i} 
and select A™"^ = ne + <5. And for and 

gmin- gmin = mino<i<„- 1 {hs+i ± <^+l) = 

| min <i<„-i{Zi,i + i} + min <i<„-i{(5i} 



1 mino^iKn-ilZ^i+i} — maxo<i< rl -i{5i} 



and se- 




Figure 1. Arbitrary adversaries: an illustra- 
tion of two attack configurations, (a) two ad- 
versaries, (b) k=3 adversaries. 



lect A™J^ = ne + 5, to complete the proof. □ 

Theorem 1: Routes discovered by SRP in the presence of 
independent adversaries are loop-free, fresh, and accurate. 

Proof: From Lemmas 1-3. □ 

The assumption of independent adversaries in Theorem 
1 is a necessary condition to achieve freshness and accu- 
racy, which cannot be achieved if independence of adver- 
saries is weakened. In the presence of arbitrary adversaries, 
SRP provides weaker properties, discovering loop-free and 
weakly fresh routes. Informally, a route is weakly fresh if 
there exists a sequence of links, in general different than 
those comprised by the route, with each of them up at some 
point within the (iijia) interval. More precisely, we call 
an (S, T)-route= {Vo, . . . , V n } weakly fresh if for some 
j > 1, k < rt — 1, and j < k, there exists a sequence 
{Vq,V{,..., V,i} of nodes such that F ' = V 3 , V' x = V k , 
and all (V.[ , V.[ +l ) were up at some point during (ti, t 2 ) in- 
terval, and for i < j and k < i < n all (Vi, Vi+i) were up 
at some point during (t±, t%). 

Theorem 2: Routes discovered by SRP in the presence of 
arbitrary adversaries are loop-free and weakly fresh. 

Proof: Lemma 1 shows loop-freedom in the presence of ar- 
bitrary adversaries. To show weak freshness, it suffices to 
show that at least a (Vi, Vi+i) link of the discovered route 
was never up during the (ii, £2) due to the adversaries' ac- 
tions, and then show that a sequence of links (V(, V( +l ), 
< i < x — 1, for some x > 1 was up at some point dur- 
ing the (tijtz). We show two types of attacks by arbitrary 



adversaries leading to such a route, illustrated in Figure 1 . 

First, in Fig. l.(a), let {S, X, M U Y, M 2 , Z, T} be an 
(S, T) -route in the network, with X, Y 7^ 0, Z, in general 
sequences of nodes, and M\, M 2 two arbitrary adversaries. 
Mi can implement the following protocol when receiving a 
RREQ with NodeList = {X}: 

Send(RREQ, M 2 ); Bcast L (RREQ); Wait for 
RREP; 

Mi sends RREQ with NodeList = {X, Mi} directly 
to M 2 , as if an (Mi,M 2 ) link were up, using a SendQ 
that forwards a message across multiple hops (rather than 
SendLQ). Mi can do so in a way that relaying nodes 
in Y cannot identify the payload (e.g., by encrypting the 
packet). Mi also broadcasts RREQ, so that the last 
node in X adds Mi in its ForwardList and later re- 
lays the corresponding RREP. M2 relays RREQ with 
NodeList = {X, Mi, M 2 } and later returns RREP with 
Route = {Z, M 2 , Mi, X} directly to Mi, e.g., routing the 
RREP across Y. 

Each of the links in Y was up at some point in (tijfa), 
because otherwise Mi would not have received the RREP. 
If Mi, M2 were independent, M2 would have ignored the 
RREQ sent by Mi, as it would not be compliant. Sim- 
ilarly, in a variation of this attack, if M 2 first modified 
one or more entries in the RREQ NodeList and then 
Send(RREP,Mi), Mi would have ignored the RREP 
for the same reason. 

Second, in Fig. l.(b), consider an (S, T)-route 
{X,V, Mi, M 2 , . . . , M k ,V ,Y}, with M k , k > 2, arbi- 
trary adversaries, and V, V benign nodes. As long as Mi 
and M k follow the protocol, neither V nor V' can discard 
RREQ or RREP. However, any M it fori ^ l,k, can 
modify NodeList in an arbitrary manner and it suffices that 
Mj, for j > i, do not perform the checks required by the 
protocol and simply relay the protocol packets. In contrast, 
if Mi were independent, M3 for example would have ig- 
nored any non-compliant RREQ it received from M 2 . 

In all cases, since there is at least one link that was never 
up, and adversaries can 'insert' multiple such links and con- 
tribute any arbitrary values for their link metrics, accuracy 
cannot be achieved. □ 



5 Related Work 

The early work of [ 17] defined the objective of Byzantine 
robustness as the ability to discover a path of correct nodes, 
if such a path exists in the network, and proposed a reli- 
able flooding mechanism for the dissemination of link state 
updates for route discovery. However, it did not provide a 
specification for the route discovery and the properties of 
the discovered routes. More recently, formal verification of 
distance vector protocols was considered, however, in a be- 



nign environment; model checking [9 1 and interactive theo- 
rem proving [7 1 techniques were used to show loop-freedom 
for AODV Q. 

A small number of works considered formal methods 
and secure routing protocols for ad hoc networks. 1 1 1 1 ana- 
lyzed SRP using BAN logic, which, invented for modeling 
authentication protocols, lacks the expressiveness to model 
the operation of a routing protocol. [ 19] extended the Strand 
model [6] to allow the description of ad hoc routing proto- 
cols, and defined as goals for secure routing the ability to 
discover a route and then the ability to communicate across 
a route termed as stable. This, however, is orthogonal to the 
specification of the route discovery, which, as stated in |fl9l , 
is not addressed. 

A more recent work |3|, transcribes a simulation tech- 
nique previously used to prove the security of cryptographic 
protocols: real-world and ideal-world system models, along 
with two models for the adversary, one for each system, 
need to be defined. Then, a routing protocol is secure if the 
outputs of the ideal and the real-world systems are indistin- 
guishable. In the ideal world, where essentially the adver- 
sary is thwarted, routes termed inexistent are never returned 
to correct nodes Q. Nevertheless, this is not a proper def- 
inition of route properties. To illustrate this, let us assume 
that an existent route's links are always up; then, a route 
can exist but have loops. A more important shortcoming 
is revealed by the discussion of our freshness property: a 
route may cease to exist right after or during its discovery, 
or it may have never existed and yet be returned to a correct 
node; e.g., consider a reactive protocol wherein a link close 
to the destination breaks as the route reply approaches the 
source, or, links that are up only when the query /reply pack- 
ets traverse them. J5] QjD assume that the topology is stable 
throughout the analysis. 

Previous notions of adversarial models alluded to the in- 
dependence definition (e.g., non-colluding nodes in [11|), 
or considered actions specific to a particular routing pro- 
tocol functionality (e.g., [18]), or defined adversaries with 
respect to their physical presence and credentials they pos- 
sess lHOl . Each of those approaches has its merits, but 
our model is general enough to encompass and extend over 
those. Our adversary model is based on how messages are 
handled, and it is independent of the actual networking pro- 
tocols) and the physical location of the code implementing 
them. Moreover, our reasoning does not consider only a 
single attacker (e.g., [3Q, but allows and utilizes multiple 
adversaries, either independent or arbitrary. 

6. Conclusions 

The contribution of our work is to provide a framework, 
comprising a network model, an adversary model, and a 
routing specification, to enable reasoning on the correctness 



of secure routing protocols. We provide definitions of all 
three components, and analyze protocols with diverse func- 
tionality. The identification of a number of attacks demon- 
strates the effectiveness of our framework, which can be the 
basis for the analysis of any secure routing protocol. It can 
also be the basis for methods that seek to automate the ver- 
ification of secure routing protocol properties. All these di- 
rections, along with elaborating on the adversary model and 
analyzing other protocols in the literature, are topics of our 
on-going and future research. 

APPENDIX 

A. Basic SRP 

Protocol Invocation: A source node (S) initiates a route dis- 
covery for a destination node (T) only if no route discovery is un- 
der way for the same node T at the time of invocation. Otherwise, 
a route discovery is performed at a later invocation and only after 
the conclusion of the ongoing route discovery. The route discov- 
ery is triggered when no S, T routes are available at S, or it can be 
triggered by mechanisms independent of the routing protocol. 

1. Route Query Generation: S generates a route query or 
route request packet (RREQ). 

1.1. The route request includes the querying node S, the 
sought destination T, a query identifier Q that was not 
previously used, an authenticator A = /k(S,T,Q) 
calculated as a function of the route query fields and a 
key K, and an empty NodeList. 

1.2. The node transmits the route request, i.e., 
Beast l(RREQ), and it initializes a ReplyWait 
timer. 

2. Route Query Processing: Each node receiving a RREQ 
determines if its own identity matches the sought destination. 
If not, it processes the request either as the querying node or 
as an intermediate node. Otherwise, it processes the request 
as the destination. 

2.1. Route Query Processing at the Querying Node: 

2.1.1. S initializes an empty ForwardList for each 
RREQ it generates. 

2.1.2. S adds to the ForwardList each neighbor V 
it overhears relaying RREQ with NodeList — 
{V}- 

2.2. Route Query Processing at Intermediate Nodes: 

2.2.1. Each Vk node invokes the 
PreviouslySeen(RREQ) routine to specify if 
RREQ has been previously processed. If yes, 
the RREQ is discarded. Otherwise, 

2.2.2. Vk extracts the last entry of the NodeList and 
verifies this is the address of its precursor T4_iQ 
If not, RREQ is discarded. Otherwise, 

4 I.e., the node that previously Beast l(RREQ) now processed; if 
NodeList = 0, the precursor must be S. 



2.2.3. Vk checks the NodeList for duplicate entries; if 
a loop is detected, RREQ is discarded. Other- 
wise, 

2.2.4. Vk appends its own identity to the RREQ, 
updating NodeList = {NodeList, Vk}, and 
Bcast L (RREQ). 

2.2.5. Vk initializes an empty ForwardList for 
each RREQ it relays. It then adds to 
the ForwardList each neighbor V it over- 
hears relaying RREQ with NodeList — 
{NodeList, V}. 

2.3. Route Query Processing at Destination Node: 

2.3.1. T invokes the Previously Seen(RREQ) rou- 
tine to check if RREQ has been previously pro- 
cessed. If so, the RREQ is discarded. Other- 
wise, 

2.3.2. T extracts the last entry of the NodeList, veri- 
fies that this is the address of its precursor, and 
discards RREQ if there is a mismatch. Other- 
wise, 

2.3.3. T checks if there is any duplicate entry in 
NodeList. If a loop is detected, it discards the 
RREQ; otherwise, 

2.3.4. T calculates /k(S, T, Q) and compares it to A, 
If they are not equal, RREQ is discarded; oth- 
erwise, T generates and returns a route reply to 
S. 

3. Route Reply Generation: T generates a route reply 
(RREP). 

3.1. The RREP packet comprises: 

• The querying node S 

• The destination T 

• The query identifier Q 

• A Route list that contains the discovered route 
and also serves as the information necessary 
for RREP to be forwarded across the network 
towards S. To determine Route, T extracts 
the identifiers of the intermediate nodes previ- 
ously accumulated in the RREQ NodeList, 
namely, Vi, Vi, . . . , V n -x- T stores them in re- 
verse order in the RREP, setting Route — 
V„-i,...,V 2 ,Vi. And, 

• An authenticator A' = fic(S, T, Q, Route). 

3.2. The destination transmits the RREP to the first entry 
of the Route list: Send L {V n -\,RREP). 

4. Route Reply Processing: 

4.1. Each Vk, including S, verifies that its successor Vfc+Jf] 
is indeed the node that now forwards the RREP. If 
not, it discards RREP. Otherwise, 

4.2. Vk verifies that Vk+i G ForwardList, unless the 
successor is T. If not, it discards RREP. Otherwise, 

5 I.e., the node entry prior to Vk in the RREP Route list, or T if Vk 
is the first entry in Route. 



4.3. Vk checks if there is any duplicate entry in Route; if 
yes, it discards RREP. Otherwise, 

4.4. Vk relays the reply to its predecessor, Vk-i, 
i.e., the next entry in the Route list or S; 
Send L {V k -i,RREP). Once RREP reaches the 
source, 

4.5. S calculates and compares Jk (S, T, Q, Route) to A' . 
If there is not a match, S rejects the reply. Otherwise, 
it accepts the reply, and, 

4.6. S extracts the Route entries to obtain the 
{S,V lt ...,V n -i,T} route. 

5. Route Reply Timeout: The ReplyWait timer may expire 
in either of the following cases: (i) no replies from T, in 
response to the query identified by Q, were accepted by S, 
or, (ii) at least one reply from T, in response to the query 
identified by Q, was accepted by S. In the former case, the 
route discovery is considered failed, while, in the latter case, 
the route discovery concludes, and S ignores route replies 
that are further delayed. 

5.1. Route Discovery Failure: S initiates a new route dis- 
covery as in Step 1, using an updated value for the 
ReplyWait timer (Step 1.2). To calculate this value 
between ReplyW ait min and ReplyW ait max , S in- 
vokes an Update(ReplyW ait) routine that returns an 
equal or higher value than the one previously used for 
the failed route discovery. 

5.2. Route Discovery Conclusion: Upon accepting a 
RREP from T identified by Q, S considers the dis- 
covery concluded after at least ReplyW aitmin sec- 
onds elapse from the corresponding query generation, 
allowing then for a new route discovery, if necessary. 
If so, the ReplyWait timer is reset, and S invokes 
Update(ReplyWait) to select ReplyW aitmin as 
the new route discovery timer value (Step 1.2). 

Definition 3: A route discovery is the current route discovery dur- 
ing the period of time that elapses from the generation of the route 
query (Step 1) till the earlier of the following two events: the ex- 
piration of the ReplyWait timer (Step 5.1 and 5.2), or a route re- 
discovery (Step 5.2). 

B. Augmented SRP 

The following steps are those that are different or added to the 
functionality of the basic SRP defined above. 

1. Route Query Generation: 

1.1. The route request includes the querying node S,..., an 
an empty NodeList, and an empty MetricList. 

2. Route Query Processing: 

2.1. Route Query Processing at the Querying Node: 

2.1.1. Each neighbor V that processes and is overheard 
forwarding a RREQ with NodeList = {V} 
and MetricList = {mj x } is added to the 
ForwardList if and only if |mo,i — mh,i I < e - 



2.2. Route Query Processing at Intermediate Nodes: 

2.2.4. .a (before 2.2.4.) Vk checks if the number of en- 
tries in the MetricList is equal to the number of 
entries in the NodeList. If not, it discards the 
RREQ. Otherwise, 

2.2.4. Vk appends its own identity to the RREQ, 
NodeList, it appends rn\_ 1 k to the 
MetricList and Bcast L (RREQ). 

2.2.5. Vk initializes an empty ForwardList for 
each RREQ it relays. Each neighbor 
Vk+i that is overheard relaying RREQ 
with NodeList — {NodeList, Vk+i} and 
MetricList = {MetricList, m'^+i} ls 
added to ForwardList along with m^ 1 ^ if 
and only if |m£ ]fc+1 - rn k +^ +1 \ < e. 

2.2.7. Vk stores ms,k, the route prefix metric calculated 
from the RREQ MetricList. 

2.3. Route Query Processing at Destination Node: 

2.3.4. .a (before 2.3.4) T checks if the number of en- 
tries in the MetricList is equal to the number 
of entries in the NodeList; if not, it discards the 
RREQ. 

3. Route Reply Generation: the destination T generates a 
route reply (RREP) packet comprising: 

• ... 

• MetricList containing all the link metrics accu- 
mulated in the RREQ along with m"_ li?l (note: 
m"_ l n = m^_ 1T ). Link metrics are also reversed, 
in order to correspond to the RREP Route entries. 

• A' = f K (S,T,Q, Route, MetricList). 

4. Route Reply Processing: 

4.2. Vk verifies that Vk+i € ForwardList, unless the 
successor is T. 

4.2.1. If Vk is T's predecessor (i.e., k = n — 1), it 
checks whether \ra\ T — m\ T \ < e. If not, it 
discards RREP. Otherwise, 

4.2.2. Vk checks if ms,k = m's fc> where m' s fc is the 
aggregate value calculated from the link metric 
values reported in the RREP Route for links 
(14, Vfc+i), k < i. If not, it discards RREP. 

4.5. S calculates and compares 

fii{S, T, Q, Route, MetricList) to A'. If there is a 
match, S accepts the reply, and rejects it otherwise. 
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